InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/bridge/90dec.min

Text File | 1993-02-17 | 11KB | 347 lines

CURRENT_MEETING_REPORT_


Reported by Maurice Turcotte/Racal

BRIDGE Minutes

Fred Baker gave a recap of the Knoxville meeting and the subsequent
activity on the Bridge-Mib mailing list.

Fred then outlined the objectives of this meeting, which were


   o to decide on which proposed MIB to pursue, and
   o to then evaluate each of the MIB variables one by one.  The two
     proposals were Richard Fox's and
     McCloghrie/Decker/Langille/Rijsinghani's.


Each MIB ``camp'' was asked to give an overview of their respective
proposal.  For reference, ``MDLR'' is the Multiple Vendor MIB, and
``Fox'' is Richard Fox's MIB in the discussion that follows.

Richard Fox explained the historical background and philosophical
underpinning of his MIB. It was acknowledged that this proposal predated
the other.  His goal was to have a MIB that was as general as possible,
and did not favor one implementation over another.  He tried to tie the
Source Routing and Transparent Bridge variables together, more than has
been done elsewhere.  He also indicated that he felt we should stay
close to the IEEE specs.  The high level organization of the MIB was
presented.  It was organized into three main areas, Transparent Bridge,
Spanning Tree, and Source Routing.

Anil Rijsinghani presented the MDLR proposal.  He explained the
structure of the MIB, as laid out on page 6 of the document, and
explained that, for the most part, it covered IEEE 802.1d Bridges.

Bob Stewart asked that we keep in mind the network manager, the human
kind, in our discussion.  This precipitated a discussion of the
definition of network management.



                                   1






After numerous folks had their say about the true meaning of network
management, it was proposed that each camp talk about the differences
between the two proposals.

The main differences, other than organization, were in the Source
Routing area.  A discussion revolved around the source routing cache
table.  The MDLR proposal had none, and the Fox proposal had an optional
table.  These points were made primarily by Keith McCloghrie and Richard
Fox.

Another difference claimed by Richard Fox is that his MIB has multi-port
source routing capability, which explained why his MIB works and the
other MIB fails.  Fred Baker talked about the use of the Target Segment
to do multi-port bridging via a ``virtual ring'' in the bridge.  Anil
Rijsinghani pointed out the the real question here was whether an
implementation should be inferred by the MIB.

Keith McCloghrie noted that a significant difference is the size of the
MIB, the MDLR MIB having 70 odd variables and the Fox MIB having 132.
There was some confusion about the exact number, but Richard Fox said
that he included more than necessary with the hope of removing useless
variables as part of the RFC process.

The discussion of the respective MIB proposals ended there, with Bob
Stewart and Maurice Turcotte both making the points that the MLDR MIB
was more mature, largely due to the Knoxville meeting, and that the Fox
MIB had more strength in the source routing area.

The respective authors were allowed to leave the room, and a consensus
was reached in their absence.  We agreed to continue with the MLDR draft
and invite Richard Fox to be added as an author, if he wanted to
contribute to the document.  His expertise in Source Routing was
acknowledged and solicited.

We then attempted to move on to the objects.  First, however, a
discussion of the Bridge/Router model errupted.  This contentious issue
became apparent when the relationship between the ifTable counts and the
bridge port counts was brought up for discussion.  It took the remainder
of the morning session and a good deal of the afternoon session to agree
to disagree.  The one point that seemed unanimous, however, was that
counts on an interface could not replace the counts on a bridge port.
In other words, ifInOctets in MIB I/II may not have anything to do with
bridgePortInOctets, if such a thing existed, which it doesn't.

There were two interconnected architectural issues involved in the
Bridge/Router model discussions.  The first addresses the question
``Where is the ifTable?''.  The second deals with the question, ``Where
are packets counted?''.

                                   2






A small but vociferous group maintained the the MIB I/II if group is
between layers and not necessarily associated with hardware.  In the
bridge case, the ifTable variables refer to traffic destined for this
bridge, and traffic that is forwarded by the bridge should not be
counted in the ifTable.  The picture looks like this:


                     ----------
                    |    IP    |
                     ----------
                        /\
                       /  \
                      /    \
                     /      \
                     /        \
                  -----     -----
                 | if  |   |  if |
                  ---------------
                 |    bridge     |
                  ---------------
                 | 802 |   | 802 |
                  -----     -----



The rationale for this picture is that the ifTable is intended to count
traffic that is destined for the local Network Element and that bridged
traffic is merely passed on by the MAC layer.



                                   3






In the process of tossing this idea around, another picture emerged:


                     ----------
                    |    IP    |
                     ----------
                        /\
                       /  \
                      /    \
                     /      \
                     /        \
                  -----     -----
                 | if  |   |  if |
                  ---------------
                 |    bridge     |
                  ---------------
                 | if  |   |  if |
                  -----     -----
                 | 802 |   | 802 |
                  -----     -----



The difference here is that there are interfaces (ifTableEntries) both
above and below the bridge layer.  Some attendees liked this picture.

The remainder, and the majority, favored one of these two pictures:


                     ----------
                    |    IP    |
                  ---------------
                 |    bridge     |
                  ---------------
                 | if  |   |  if |
                  -----     -----
                 | 802 |   | 802 |
                  -----     -----



                                   4






or



                  -------- ------
                 | bridge |  IP  |
                  -------- ------
                   |    \   /   |
                   |     \ /    |
                   |      X     |
                   |     / \    |
                   |    /   \   |
                   -----     -----
                  | if  |   |  if |
                   -----     -----
                  | 802 |   | 802 |
                   -----     -----



The main point here is that the ifTable counts all traffic that is
received or transmitted by the 802.x port.  For a bridge this means an
Ethernet chip put in promiscuous mode receives and counts a LOT of
traffic.

The difference between the two previous pictures illustrates the second
issue.  There were three camps present.  The first thought that all
traffic entering a bridge should be directed to the bridge software.
This means that the counts on a bridge port basis are redundant, and the
ifTable counts in MIB I/II are sufficient.  The picture:



                     ----------
                    |    IP    |
                  ---------------
                 |    bridge     |
                  ---------------
                 | if  |   |  if |
                  -----     -----
                 | 802 |   | 802 |
                  -----     -----



The second point of view was that locally destined packets, from the
bridge point of view, should not be counted in the bridge software
instrumentation, largely because the bridge software never sees this
traffic.  This traffic may be forwarded by a higher layer, such as a
router or trap exploder.  The point is that each incoming packet goes to

                                   5






one and only one software layer, even if it is a multicast.  The
picture:



                   --------
                 /| bridge |
                /  --------
         ----  /     ----
        | if | -----| IP |
         ----  \     ----
                \
                 \ -------------------
                  | other Application |
                   -------------------



The third point of view held that incoming traffic, multicast in
particular, may be directed, and counted, in more than one software
module.  The same picture applies, with the distinction that the paths
are shared.

The architectural issues were discussed at great length, and closure was
not reached.  It was decided to carry on the discussion via mail on the
net.

The final topic discussed in the afternoon had to do with filtering.
Fred Baker gave an overview of the IEEE 802.1d definition, and then
reviewed the proposal that was put out on the net as a result of the
Knoxville meeting.  It was pointed out that everyone does filtering in
their own way and reaching consensus may be impossible and best left up
to the enterprise MIBs.

Bob Stewart suggested that an alternative was to define every possible
type of filter and use an Object ID to define which one is used by this
bridge.

Anil Rijsinghani presented the IEEE 802.1d approach and argued for
including it as an optional table.  A suggestion was also made that it
might be extended to include source addresses.

A consensus was reached to include this table as Optional, without
source addresses.  This represents a middle ground between camps wanting
no static filtering, 802.1 static filtering, and rather complete source
and destination address filtering.



                                   6






It was also agreed to include the number of ports as part of the MIB.

It was agreed that static and permanent forwarding table entries
appeared the same in the MIB. The distinction is that permanent entries
are saved on some reliable storage medium and present at startup.  For
the bridge MIB there is no distinction.

Attendees

Karl Auerbach            [e-mail]
Fred Baker               [e-mail]
Terry Bradley            [e-mail]
Theodore Brunner         [e-mail]
Jeffrey Buffum           [e-mail]
Chris Chiotasso          [e-mail]
Anthony Chung            [e-mail]
James (Chuck) Davin      [e-mail]
Nadya El-Afandi          [e-mail]
Gary Ellis               [e-mail]
Richard Fox              sytek![e-mail]
Frank Kastenholz         [e-mail]
Shimshon Kaufman
Jim Kinder               [e-mail]
Cheryl Krupczak          [e-mail]
Peter Lin                [e-mail]
Keith McCloghrie         [e-mail]
Donna McMaster           [e-mail]
David Perkins            [e-mail]
Jim Reinstedler          [e-mail]
Anil Rijsinghani         [e-mail]
Bob Stewart              [e-mail]
Emil Sturniolo
Maurice Turcotte         [e-mail]
Fei Xu                   [e-mail]



                                   7